* 



(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 

(19) Wor,d lllllim 

(43) International Publication Date (10) International Publication Number 

11 January 2001 (11.01.2001) PCT WO 01/03365 Al 



(51) International Patent Classification 7 : H04L 9/00, 

G06F 17/60, H04K 1/00 

(21) International Application Number: PCT/US00/18583 

(22) International Filing Date: 6 July 2000 (06.07.2000) 

(25) Filing Language: English 

(26) Publication Language: English 

(30) Priority Data: 

60/142,495 6 July 1999 (06.07.1999) US 

09/401,450 22 September 1999 (22.09.1999) US 

(63) Related by continuation (CON) or continuation-in-part 
(C1P) to earlier application: 

US 09/401,450 (CON) 

Filed on 22 September 1 999 (22.09. 1 999) 

(71) Applicant (for all designated States except US): MAT- 
SUSHITA ELECTRIC INDUSTRIAL CO., LTD. 
• [JP/JP]; 1006, Oaza Kadoma, Kadoma City, Osaka 
| 571-8501 (JP). 



(72) Inventors; and 

(75) Inventors/Applicants (for US only): DONDETI, Laksh- 
minath, R. [EG/US]; Apt. 15, 9378 Ohem Plaza, Omaha, 
NE 68127 (US). MUKHERJEE, Sarit [IN/US]; 920 
Bradley Court, Mount Laurel, NJ 08054 (US). SAMAL, 
Ashok [EG/US]; 6821 South 34th Street, Lincoln, NE 
68516 (US). 

(74) Agents: STOBBS, Gregory, A. et al.; Harness, Dickey & 
Pierce, P.L.C., P.O. Box 828, Bloornfield Hills, MI 48303 
(US). 

(81) Designated States (national): CN, JP, KR, US. 

(84) Designated States (regional): European patent (AT, BE, 
CH, CY, DE, DK, ES, Fl, FR, GB, GR, IE, IT. LU, MC, 
NL, PT, SE). 

Published: 

— With international search report. 

For two-letter codes and other abbreviations, refer to the "Guid- 
ance Notes on Codes and Abbreviations" appearing at the begin- 
ning of each regular issue of the PCT Gazette. 



=5 (54) Title: DISTRIBUTED GROUP KEY MANAGEMENT SCHEME FOR SECURE MANY -TO-MANY COMMUNICATION 




SECRET 
KEY 
GENERATOR 



IT} 



O 



(57) Abstract: A group key management system (20) and method for providing secure many-to-many communication is presented. 
The system (20) employs a binary distribution tree structure (26). The binary tree (26) includes a first internal node having a first 
branch and a second branch depending therefrom. Each of the branches includes a first member (22, 22a) assigned to a corresponding 
leaf node. The first member (22, 22a) has a unique binary ID (24) that is associated with the corresponding leaf node to which the 
first member (22, 22a) is assigned. A first secret key (28) of the first member (22, 22a) is operable for encrypting data to be sent 
to other members (22, 22a). The first member (22, 22a) is associated with a key association group (33) that is comprised of other 
members (22, 22a). The other members (22, 22a) have blinded keys (30). A blinded key (30) derived from the first secret key (28) of 
the first member (22, 22a) is transmitted to the key association group (33). Wherein, the first member (22, 22a) uses the blinded keys 
(30) received from the key association group (33) and the first secret key (28) to calculate an unblinded key of the first internal node. 
The unblinded key is used for encrypting data that is communicated between members (22, 22a) located on branches depending from 
the first internal node. 
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DISTRIBUTED OROUP KEY MANAGEMENT S fflFME FOR 
SECURE MANY-TO-MANY COMMUNICATION 



Prnw Reference to Related Applications 

This application claims the benefit of the filing date of U.S. provisional 
5 application No. 60/142,490 filed July 6, 1 999. 

Back ground and Summary of t he Invention 

The present invention relates generally to secure communication. More 
particularly, the invention relates to a system for providing secure communication 
between many senders and many members. 
10 Secure multicasting over a network such as the Internet is employed in several 

applications, such as stock quote distribution, private conferencing, and distributed 
interactive simulation. Some of these applications have a single sender distributing 
secret data to a large number of users while the others have a large number of users 
communicating privately with each other. Several approaches have been proposed in 
15 the recent past to support group communication between one sender and many 
members. The few solutions that exist to facilitate secure communication between 
many senders and many members suffer from a common failing; they employ some 
form of centralized group control. 

Multicasting is a scalable solution to group communication; many-to-many 
20 secure multicasting protocols must also be scalable. Group access control, secret key 
distribution and dynamic group management are three major components of a secure 
group communication protocol. Most of the existing one-to-many secure multicast 
protocols use a centralized entity, the group manager to enforce access control and 
distribute secret keys. When the multicast group membership is dynamic, the group 
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manager must also maintain perfect forward secrecy. This is to guarantee that members 
cannot decrypt secret data sent before they join the group and the data sent after they 
left. The group manager changes the appropriate secret keys when a member joins or 
leaves, and distributes them to the corresponding members. The rekeying process must 
5 be scalable; the key distribution overhead should be independent of the size of the 
multicast group. 

Although it presents a single point of attack and failure, using a centralized 
entity for group control is natural for one-to-many secure multicasting. However, in the 
presence of multiple senders, it is desirable that the multicast group remains operational 

10 as long as at least one sender is operational. In other words, many-to-many secure mul- 
ticasting calls for decentralized control of the group. Access control, key distribution 
and dynamic group management tasks should be delegated to all the senders. It is desir- 
able to evenly distribute access control responsibilities and protocol processing 
overhead among all the senders in the group. 

15 Only a few secure many-to-many group communication protocols exist in the 

literature. However, all such protocols in the literature use centralized group control 
and thus are prone to single point of attack as well as failure. One protocol exposes 
secret keys to third party entities which assist in key distribution and additionally 
employs a centralized "group security controller" (GSC) for group management. 

20 Another protocol suggests placing equal trust in all the group members. Members 
joining early generate the keys and distribute them to the members joining late. While 
this protocol works in principle, it is susceptible to collusion amongst the members. It 
is possible to have a very small subset of members controlling the group, allowing 
uneven distribution of group control and key distribution overhead. It is desirable for 

25 the structure of a communication protocol to prevent collusion between group 
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members. 

Any secure group communication protocol has three major components, group 
access control, secret key distribution and dynamic group management. Senders are 
responsible for controlling access to the secure multicast group. All members' 
5 authentication must be verified before they can join the group. Data is encrypted for 
privacy reasons before being sent to the group. The senders are responsible for 
distributing the data encryption keys to members in a secure and scalable fashion. 
Finally, the senders are responsible for maintaining perfect forward secrecy. To ensure 
perfect forward secrecy, sendees) should change secret keys when a host joins or leaves 
10 the group. This rekeying process should be secure as well as scalable. 

The requirements and desirable characteristics of a secure many-to-many 
protocol are as follows. A secure group communication scheme must be scalable. 
More specifically, key distribution overhead must be scalable as the number of 
members (or senders) in the group increases. All senders must be trusted equally and 
15 the group must be operational if at least one sender is operational. It is desirable to 
distribute access control and dynamic group management tasks to all senders. This 
allows the joins and leaves to be processed locally, thus avoiding global flooding of 
control traffic. Distribution of group management tasks also avoids performance 
bottlenecks and eliminates single points of attack in a multicast group. Finally, the 
20 protocol should be able to avoid or detect and eliminate any colluding members or 
senders efficiently. 

The present invention presents a group key management system and method for 
providing secure many-to-many communication. The system employs a binary 
distribution tree structure. The binary tree includes a first internal node having a first 
25 branch and a second branch depending therefrom. Each of the branches includes a 
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first member assigned to a corresponding leaf node. The first member has a unique 
binary ID that is associated with the corresponding leaf node to which the first 
member is assigned. A first secret key of the first member is operable for encrypting 
data to be sent to other members. The first member is associated with a key 

5 association group that is comprised of other members. The other members have 
blinded keys. A blinded key derived from the first secret key of the first member is 
transmitted to the key association group. Wherein, the first member uses the blinded 
keys received from the key association group and the first secret key to calculate an 
unblinded key of the first internal node. The unblinded key is used for encrypting 

10 data that is communicated between members located on branches depending from the 
first internal node. 

For a more complete understanding of the invention, its objectives and 
advantages, refer to the following specification and to the accompanying drawings. 



Brief Description of the Drawings 

15 Fig. 1 is a diagram illustrating a communication system for many to many 

communication among members of a communication group; 

Fig. 2 is a diagram of a key distribution tree arranged in accordance with the 
principles of the present embodiment of the invention; 

Fig. 3 is a diagram of a member joining a communication system arranged in 
20 accordance with the principles of the present embodiment of the invention; 

Fig. 4 is a diagram of a member leaving a communication system arranged in 
accordance with the principles of the present embodiment of the invention; 

Fig. 5 is a sequence diagram showing a procedure for determining the members 
of a key association group; 

4 
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Fig. 6 is a sequence diagram showing a procedure for encrypting data; 

Fig. 7 is a sequence diagram showing a procedure for joining the communication 

system; 

Fig. 8 is a sequence diagram showing a procedure for leaving the communication 
5 system; and 

Fig. 9 is a diagram illustrating a communication system for few to many 
communication among members of a communication group. 

Description of the Preferred Embodiment 

Referring to Figure 1, a scalable, secure multicasting protocol that supports 
10 many-to-many communication according to the principles of the present invention is 
illustrated. The present embodiment of the invention is a communication system 20 
employing a distributed tree-based key management scheme (DTKM) for secure 
many-to-many group communication. The system 20 is scalable and members 22 are 
trusted equally. The system 20 delegates group control responsibilities and key 
15 distribution tasks evenly to the members. 

Each member 22 is assigned a binary ID and these IDs are used to define key 
associations for each member 22. Members in the key association groups 22a are 
contacted to report membership changes and to exchange keys. The members 22 are 
trusted equally and all of them may be senders. Prospective members may contact any 
20 active member to join the group. Active members verify new members' credentials and 
assign them a unique binary ID 24. The ID assignment is done locally without any 
need to lookup a global space of IDs. The ID assignment process illustrates the 
distributed nature of the protocol. The new member initiates the rekeying process. 
Note that rekeying is done to ensure perfect forward secrecy. Leaves are processed 
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similar to joins; the neighbor (neighbors are determined based on IDs) of the departing 
host is required to notice the departure and initiate the rekeying process. Key 
associations help delegate key distribution overhead evenly among all the members of 
the group. 

5 Members are represented by the leaves of a binary key distribution tree 26. 

Each member 22 generates a unique secret key 28 for itself and each internal node key 
is computed as a function of the secret keys of its two children. AJ1 secret keys 28 are 
associated with their blinded versions 30, which are computed using a one-way function 
32. Each member 22 holds all the unblinded keys of nodes that are in its path to the 
10 root and the blinded keys of nodes that are siblings of the nodes in its path to the root. 
The contribution of the unique secret key toward the computation of the root key gives 
each member 22 partial control over the group. A join/leave requires only the keys in 
the path to the root from the joining/departing host to be changed. Thus, each 
membership change necessitates only 0(log n) messages where n is the number of 
15 members in the group. Thus the protocol is scalable. 

Members of the multicast group are represented by leaf nodes of a key 
distribution tree. The key distribution tree is strictly binary, i.e., each internal node has 
exactly two children. Each member generates a unique secret key 28 which is the 
member's contribution towards the generation of the internal node keys including the 
20 root key. Internal nodes are associated with secret keys and these keys are computed as 
a function of their children's keys. The root key is computed similarly and is used for 
data encryption. For each secret key, k, there is a blinded key, k\ and an unblinded key. 
The blinded key is computed by applying a given one-way function to the secret key. 
Given a blinded key that is calculated with a one-way function, it is computationally 
25 infeasible to compute the unblinded counterpart of the blinded key. Each member 22 
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knows all the keys of the nodes in its path to the root of the tree and the blinded keys of 
siblings of the nodes in its path to the root of the tree and no other blinded or unblinded 
keys. The blinded keys are distributed by members that are owners and authorized 
distributors of those keys. Each member 22 computes the unblinded keys of the 
5 internal nodes of the tree in its path to the root and the root key itself, using the blinded 
keys it receives and its own secret key 28. A mixing function 34 is used to compute 
internal node keys from the blinded keys of the node's children. 

Each node is assigned a binary ID 24 and is responsible for generating a secret 
key 28. The member 22 associated with the node also computes the blinded version 30 
10 of its key 28 and shares it with its immediate neighbor in the key distribution tree 26. 
Table I provides psuedocode of a Find-Neighbor algorithm that takes a binary ID of 
node A and returns the binary ID of A's neighbor. 

Table I. 



Find Neighbor Module 

15 Find_Neighbor(X = b h b h ., ... b,), X is a binary ED, where b s for 1 < i <h, is a binary 
digit 

begin 

X , = b h b M ...b, 
if (leafnode(X') = "true") 
return X'; 

20 else if (intemal_node(X*) = "true") 

do 

X' = X'0; 
while (leaf_node(X') = "false"); 
return X* 

25 end 

Notes: ^ c , 

1. leaf_node(X) returns true if X is a leaf node of the key distribution tree; false 

otherwise. 

2. intemal_node(X) returns true if X is an internal node of the key distribution tree; 
30 false otherwise. 
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With reference to Figure 2, following the FindJSIeighbor algorithm; H(l 1 1 0)'s 
neighbor is 1(1 1 1 1), and G(l 1 0) ! s neighbor is H(l 1 1 0), Neighbors with IDs 24 of 
same length (H and I in Figure 1) are referred to as immediate neighbors and they 
exchange blinded versions 30 of their secret keys 28 with each other. If a pair of 

5 neighbors have different ID lengths (G and H in Figure 1), the member with the smaller 
ID size, sends the blinded version 30 of its secret key 28 and receives the blinded key 
30 of the corresponding internal node of same ID length from the member with the 
larger ID length (G receives k'm from H). Using the new keys that are received, the 
members 22 compute their parents secret key 28. A mixing function (typically an XOR 

10 function) 34 is used to compute internal node keys. For example in Figure 2, C and D 
apply the mixing function, m, 34 to the blinded keys k'oio and k'on to compute the 
internal node key koi - 

Blinded keys 30 are exchanged between members of a key association group 
22a in the system 20. Key associations are designed to delegate the task of key 

1 5 distribution evenly among all the members 22. Each member 22 needs as many blinded 
keys 30 as the length of its ID 24, to compute the root key. Each blinded key 30 is 
supplied by a different member of its key association group 22a. For each bit position 
in a member's ID, there exists a member 22 that supplies the corresponding blinded key. 
The following module, Find_Key_Association 33, returns the ID 24 of the member 22 

20 and the secret key 28 it supplies, corresponding to a given bit position in a member's ID. 

Table II. 

Find Key Association Group Module 

Find__Key_Association(X = b h bh-i ... bi, i) 
begin 

Xi=b h b h . I ...b m b i b M ...b 2 b I ; 

8 



r 



WO 01/03365 



PCTAJS00/18583 



if (leaf_node'(Xi) — "true") 
return (Xj, k'j); 

ki = k b b b 11 .,...b Ul b i 

else if (intemal_node(Xi) = "true") 
do 

5 Xi = XiO; 

while (leaf_node(XO = "false"); 
return(Xi, k'j); 

else 

do 

10 Xi = right_shift(Xi,l)); 

while (leafnode(Xi) = "false"); 
return (Xu k\); 

end 

Notes: . . 

15 1. leaf_node(X) returns true if X is a leaf node of the key distribution tree; false 

otherwise. . 

2. internal_node(X) returns true if X is an internal node of the key distribution tree; 

false otherwise. 

3. right_shift (X, i), takes a binary ID X = b„b h -i - b 2 , bi and a number, i, as Us 
20 inputs and right shifts X for i time(s). The output will be b h b h -i ... b w . 



Referring to Figures 2 and 5, the key association module 33 applied to H(1110) 
40 is illustrated. At step 60, a binary ID 24 corresponding to a node is loaded. The bit 
positions are then complemented, step 62. Here, we complement the corresponding bit 
positions 1, 2, 3, 4, and get 1(1111) 42, 1100, 1010, 0110. At step 64, if the node is a 
25 leaf node, the blinded keys corresponding to the members of the key association group 
are obtained, step 70. Otherwise if the node is not a leaf node, then at step 66, whether 
the node is an internal node is determined. Since here, nodes with the last three IDs do 
not exist, we right-shift them by one bit position to get G(110) 44, F(101) 46, and 
D(01 1) 48 as the rest of the members in H's 40 key association group 22a, steps 66 and 
30 68. Finally at step 70, 1 42, G 44, F 46, and D 48 supply the keys k' n ,i, k' u0 , k'io, k'o 
respectively, to H 40. 

Referring to Figure 6, illustrated is the root key computation process for C(010) 
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50. At step 72, C 50 generates the key k 0) o and sends its blinded version k'oio 
(computed using the given one-way function 32, steps 74 and 76) to D(011) 48. 
Similarly, D 48 sends k'oii to C 50. Both C and D can then individually compute koi by 
applying the given mixing function 34 to k'oio and k' ou . Next, C 50 sends k'oi to 

5 A(000) 52 and receives k'oo in return, step 78. After the key exchange, both A 52 and C 
50 can compute ko. After this step, C 50 and G 44 exchange k' 0 and k'i with each other. 
The root key is computed as a function of k' 0 and k' w step 80. Following similar steps, 
each member 22 of the multicast group acquires or computes k' 0 and k', and then 
computes the root key. All keys are encrypted with the recipient's public key before 

1 0 transmission. Note that C 50 receives only the blinded keys of the siblings of the nodes 
in its path to the root 54. Using those keys, it can compute the unblinded keys of the 
nodes in its path to the root 54. C 50 encrypts a message with the root key that has been 
computed, step 82. The encrypted message is multicast by C 50 to members 22 of the 
communications system 20, step 84. 

1 5 Neighbor-of Set Definition 

Each member, X 22 also maintains a neighbor-of set, N x , which consists of all 
members for which X is the neighbor. In our example, N H consists of both G 44 and / 
42. Each member 22 monitors the members in its neighbor-of set and initiates ID 
update and key-update processes when a neighbor leaves. The elements of neighbor- 

20 of sets may change during joins or leaves and the join and leave protocols provide 
information to members to update these sets as well. In the system 20, after a join or 
leave occurs, during the rekeying process all members 22 recognize the group 
membership change. Each member 22 is responsible for updating its neighbor-of set 
using the joining or leaving host's ID 24. 
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Join Protocol Procedure #1 

A prospective member may join at any node of the key distribution tree 26. 
However, to enhance efficiency it is desirable to control at which node a prospective 
member joins in order to keep the key tree balanced. The system 20 locally balances 
5 the tree 26 by choosing members 22 in the tree that are within an administratively or 
Time-to-Live (TTL) scoped area. An example of an administratively scoped area 
includes limiting a message to a controllably expanded area such as a 5 person LAN, to 
a department LAN, to a division LAN, to a corporate WAN. An example of a TTL 
scoped area includes limiting the number of router hops a message may travel. The 
1 0 prospective members join at a local member of the multicast group with the smallest ID 
length within the scoped area. Undesirable alternative approaches require one or more 
entities to keep a snap shot of the key distribution tree 26. For example, to keep track 
of all members 22 of the group and their positions in the key tree 26, either member 
status report messages are broadcast to the whole group or a centralized entity that 
15 keeps track of all joins and leaves. The first alternative creates excessive network 
traffic and the second has a single point of failure. 

Referring to Figures 3 and 7, J 56 is a new member which joins at C 50, step 86. 
Upon verifying J's credentials, C splits its ID 010 (shown in Figure 3), keeps 0100 for 
itself and assigns 0101 to J 56, step 88. C 50a also changes its secret key 28 and sends 
20 the blinded version of its new key to J 56. J 56 generates a secret key 28 of its own and 
transmits the blinded version to C 50a, steps 90, 92, and 94. Note that all keys 
corresponding to the internal nodes in the path to the root 54 from J 56, change due to 
the join. J 56 needs all the unblinded keys of the nodes shown in black and the blinded 
keys of the nodes show in gray, in Figure 3. Notice that none of the blinded keys 
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known to C 50a have changed and thus it can compute all the new keys corresponding 
to nodes 010, 01 and 0 and the root key once it receives k'j, step 96. Now J 56 needs the 
blinded keys corresponding to 011, 00 and 1. Using the Find_Key_Association() 
module 33 presented earlier, it determines that nodes with IDs 011(D), 000(A) and 
5 110(G) are the members of its key association group, step 98. Note that these nodes 
and their neighbors also need the blinded keys that J 56 knows or can compute. To 
elaborate, J 56 sends k'oio to D 48 and receives k'on from D 48. It then computes k'oi, 
sends it to A 50, and receives k'on in return, step 100. A 50 is also required to locally 
multicast k'oi encrypted with koo, which can only be decrypted by A 50 and B 58. J 56 
1 0 can now compute k' which it sends to G 44, receives k' , in return and computes the root 
key for itself, step 102. G 44 multicasts k'o encrypted with ki, to be decrypted by E 60, 
F 46, G 44, H 40, and I 42 only. After the above key exchanges all authorized members 
will have the keys they need to compute the new root key. In all, there will be 0(log n) 
unicast messages and 0(log n) subgroup multicast messages during a join. Note that 
15 the multicast messages will be limited to a TTL-scoped or administratively scoped 
region, since they only need to be sent to selected subgroups within the multicast group. 
We generalize the join process in the following JoinO module 62. It takes the new 
member and an existing member's ID 24 as arguments. In the module, k' indicates the 

key sent by M to X. 
20 Table IE. 

Join Module 

Join(X, Y = b h b h -i ... bi) /* Y is the existing member */ 
begin 

25 Y = b h b h .i... biO; 

X=bhbh-i-.. biO; 

k x = generate_new_key(); 

i=i; 

while (i < length(X)) 
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begin 

(M, k') = Find_Key_Association(X;i); 

outgoing_key = k'n g ht_shift(x,i-i); 
send_key_from_to(outgoing_key, X, M); 
5 scoped_secure_multicast(outgoing_key, M, k); 

send_key_from_J:o(k\ M, X); 
i = i+ 1; 

knght_shia(x.i.i) = m(outgoingJcey, k'); 

end 

10 Notes: 

1 . generate_new_key 0 returns a new secret key. 

2. right_shift (X, i), takes a binary ID X = b h b h -i ... b 2 , bi and a number, i, as its 
inputs and right shifts X for i time(s). The output will be b h b h -i ... bj+i- 

3. sendJcey_from_to (key, X, Y) indicates that X sends "key" to Y. 

15 4. scoped__secure_multicast (keyl, X, key2) indicates that X encrypts keyl with key2, 
and locally multicasts it. 

5 . length(X) returns the number of bits in the binary ID X. 

6. m() is the mixing function, where kbhbh-i ...bi+i — ni(k'bhbh-i .:.bi+bi> k'bhbh-i ...bi+i bi) 



Join Protocol Procedure #2 

In another procedure for joining the multicast group, a new member sends a 
scoped multicast message to members of the multicast group it wants to join. The 
message consists of the new member's authentication information as well as its 
unicast (example: IP) address. Referring to Figures 3 and 7, C 50 responds to J's 56 
request to join, step 86. Upon verifying J's credentials, C splits its ID 010 (shown in 
Figure 1), keeps 0100 for itself and assigns 0101 to J 56, step 88. Next, C 50 changes 
its secret key and sends the blinded version of its new key as well as all the blinded 
keys it knows (shown in gray in Figure 3) to J 56. It also sends its unicast address to J 
56, since it is J's neighbor, step 104. J 56 generates a secret key of its own and 
transmits (unicasts) the blinded version to C 50a, step 106. Note that all keys 
corresponding to the internal nodes (shown in black in Figure 3) in the path to the root 
54 from J 56, change due to the join. Notice that both C 50a and J 56 can compute all 
the new keys viz., ko\ 0i A&i and ko and the root key, step 108. The children of the 
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internal nodes Oil, 00 and 1 need the blinded keys £oio> *ow and *o- C 50a is 
responsible for sending them and it uses the keys A: on, * oo, and k\ respectively, to 
encrypt them and sends the encrypted keys via multicast, step 110. Notice that: 

♦ C, J and D can decrypt k *oio> 

5 ♦ A, B, C, J and D can decrypt k oi and 

♦ A, B, . . and I can retrieve k ' 0 . 

All the above key possessions conform to the key distribution rule that all 
members know the unblinded keys in their path to root 54 and the blinded keys of the 
siblings of the nodes in their path to root 54. After the above key exchanges all 

10 authorized members will have the keys they need to compute the new root key. In all, 
there will be a single unicast message consisting of <9(log n) keys and 0(log n) 
multicast messages consisting of one key each. Notice that members need to know 
the unicast addresses of the members in their neighbor-of set. All other keys are sent 
using the group multicast address. This property contributes to the distributed nature 

15 of the protocol. Also, our protocol does not require members to keep ID to unicast 
address translation tables for all members. 

Synchronized Joins 

Internal node keys may be updated in several ways. The simplest is to 
compute an internal node key whenever any one of its children's keys change. 
20 However, in the presence of multiple simultaneous joins the simple approach may not 
work. More precisely, members in different parts of the tree 26 may have different 
versions of an internal node key, which would thereby render the group inoperable. A 
method for synchronizing simultaneous joins is therefore desirable. 

The first method, a version maintenance approach, for synchronizing 
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simultaneous joins calls for maintaining the version number of all internal node keys. 
If a member receives two versions of the same key through multicast, it uses the 
mixing (XOR) function 34 to combine both keys. If more than two versions of the 
same key are received, the mixing function 34 is applied multiple times to get the new 
5 key. Since the XOR function is associative, all members will have computed the 
same key. A disadvantage of the version maintenance approach is that each key will 
be associated with some overhead. 

An alternative method for synchronizing simultaneous joins calls for using the 
mixing function 34 to update the internal node keys on all occasions. In other words, 
10 new internal node keys are always obtained by applying the mixing function 34 on the 
old key and the new key received or computed. The second method is more efficient 
with respect to storage and the first requires less processing time to compute internal 
node keys. 



B. Leave Protocol 

15 When a member 22 leaves, its neighbor initiates the rekeying process. If the 

neighbor is the departing member's sibling, it assumes its parent's position in the key 
distribution tree. Otherwise it notifies the descendants of the departing member's 
sibling to change their IDs. In either case, the neighbor changes its secret key 28 and 
initiates the rekeying process. It sends the new keys to the members of its key 

20 association group and they are responsible for propagating the new keys to the 
appropriate members in their subgroups. In the rest of this section, we describe the ID 
update process followed by the rekeying process. 

X is the departing node and Y (= Neighbor(X)) is its neighbor, step 112. If Y 
has the same ID length as X, Y right shifts its ID by one bit position to get its new ED. If 
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Y's ID is longer than that of X, X's sibling and its descendants change their IDs as 
follows. Notice that each descendant Z of X's sibling shares a key with X. If Z = bhbh-i 
... b i+ i bjbi-i ... b 2 b la then Z's ID after the departure would be b h b h -i ... b i+ ibi-i ... b 2 bi, 
where i is the difference in the length of Z's and X's IDs plus one, step 114. In both 
5 cases, Y generates the new secret key and initiates the rekeying, step 116. In Figure 4, 
if E leaves, F gets the ID 10 and generates a new secret key; if G leaves, H and I get the 
IDs 1 1 0, 1 1 1 respectively and H generates the new secret key. 

In Figure 4, C 50 leaves the multicast group. J 56 notices the departure and 
changes its ID from 0101 to 010, and generates a new secret key 28 for itself. 
10 Consequently, internal node keys on J's path to the root 54 change and J 56 : is 
responsible for initiating key exchanges with its counterparts, 011(D), 000(A) and 
1 10(G) as defined earlier in this section. J 56 sends the blinded key k'oio to D 48. Both 
J 56 and D 48 can now compute koi. J 56 then sends k' 01 , to A 52, which is responsible 
for sharing it with all members who have koo- Finally, J 56 sends k'o to G 44, which in 
15 turn sends k' 0 to all the members that have ki. Notice that J 56 does not need any keys 
in return from D 48, A 52, or G 44, step 118; It already has the blinded keys it needs to 
compute the root key, step 120. While the departing member C 50 knows all those 
blinded keys as well, it does not know any unblinded keys it needs and thus cannot 
compute or acquire the root key. A departure results in O(logn) multicast messages, 
20 each message carrying one encrypted secret key. In the following, we provide a 
generalization of the rekeying process after a member departs from the group. 

Table IV. 

Leave Module 

Leave(X) 
25 begin 

Y = Find_Neighbor(X); 

for each Z in {descendants(sibling(X))} U {Y} 
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Z = delete_i th _bit(Z, length(Z)-length(X)+l); 
k y — generate_new_keyO; 
compute_intemal_node_keys(Y); 
i = l; 

5 while (i < length(Y)) 

begin 

(M, k') = Find_Key_Association(Y, i); 

outgoingjcey = k'n g ht_shift(Y,i-i); 

right-shift(y,i-l) 
1 0 sendJcey_from_to(outgoing_key, Y, M); 

scoped_secure_multicast(outgoing_key, M, k); /* M already has k */, 
i = i + 1; 

end 

end 

15 

Notes: 

• descendants(X) returns the members of the multicast group that are descendants of 

• If X = b h b h . 1 ...b 2 b 1 ,sibling(X) = b h b h . l ...b 2 y, 
X. 

• delete_i th _bit (X, i), takes a binary ID and an integer as its inputs and returns X with 
20 its bit position i deleted. For example if X = b h b h -i ... b i+ ibjbM ... b 2 bi, the function 

returns bhbh-i ... bj+ibj-i ... babj. 

• generate__new_key 0 returns a new secret key. 

• compute_intemal_node_keys (Y) indicates that Y locally computes all internal node 
keys and their blinded counterparts. 

25 • right_shift (X, i), takes a binary ID X = b h b h -i ... b 2 , bi and a number, i, as its 
inputs and right shifts X for i time(s). The output will be b h b h -i ... b,>i- 

• sendjcey_from_to (key, X, Y) indicates that X sends "key" to Y, 

• scoped_secure_multicast (keyl, X, key2) indicates that X encrypts keyl with key2, 
and locally multicasts it. 

30 • length(X) returns the number of bits in the binary ID X. 

• m() is the mixing function. 



Secure Data Communication 

All members in the multicast group can compute the root key with the given 
keys. A member with data to send, encrypts the data with the root key and sends it via 
35 traditional multicast channels (e.g.: MB ONE). Other members can decrypt the data 
without any further key exchanges. The protocol also allows secure subgroup 
communication. A sender may send secret data to a subgroup of members by 
encrypting the key it shares with the subgroup. 
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Group Merge 

It is possible to efficiently merge independent communication systems 
structured in accordance with the principles of the invention to form a single many-tb- 
many multicast group. To merge two groups that are of approximately equal size, we 

5 compute a new common group key by applying the mixing function 34 to the existing 
root keys. Members with IDs 1 + (example: 1, 11, 111 etc.)or IDs 0 + (example: 0, 00, 
000 etc.) may act as default representatives of a group and initiate the group merge. If 
one of the groups is substantially shallower than the other group, the shallower group 
joins at the shallowest point of the deeper tree. Such a group join is similar to a join 

10 and the member 22 with ID 0 + (or T) changes its secret key and initiates the rekeying. 

Network Partitions and the Group Leave Operation 

Neighbors may notice network partitions by following a repeated discovery 
process. For example, when a members neighbor does not send a heartbeat message, 
the corresponding member 22 may assume that the neighbor is not available or the 
15 member may initiate a discovery process to see whether others in the subgroup are 
available. Subgroup multicast addresses may be used for this discovery process. 

Note that members of each subtree in the key tree can communicate within 
themselves using the blinded key of the internal node they have in common. Thus, in 
case of network partitions, it is possible for all connected subgroups to communicate 
20 within themselves. 

Balancing the Key Tree 

The key tree should be balanced for efficient secret key distribution. The use 
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of smart join algorithms prevents the formation of an unbalanced tree. The join 
protocol calls for prospective members to join at an existing sender that has the 
smallest ID length. However, since requests for joins are sent to senders in a scoped 
(local) area, we may not have a globally balanced tree. Also, a series of leaves may 
5 result in an unbalanced tree. It is possible to re-balance the tree by forcing a group 
leave and group merge operation. Using smart selection of a location for group 
merge, we may reconstruct a balanced tree. 



Few-to-many secure group communication 

An alternative embodiment of the invention provides secure few-to-many 
10 group communication. A class of multicasting applications have a small set of 
members, the senders, sending the data and the others, the receivers, receiving the 
data. All of the senders are also receivers. Panel discussions multicast over the 
Internet, online corporate meetings where branch managers discuss strategy while 
other employees listen in are examples of few to many group communication. Some 
15 of the applications discussed above also require secrecy of data for acceptable use. In 
designing a trust model, it is apparent since the senders own the data, they must have 
control over the multicast group. In our context, control consists of group access 
control, secret key distribution etc. It is desirable that the senders have equal control, 
are trusted equally, and also bear an equal share of the protocol processing overhead. 



20 Subgroups 

Referring to Figure 9, a few-to-many communication system 122 adhering to 
the principles of the present invention is illustrated. The senders belong to a senders 
subgroup 124 sharing a common group key (Root Key 0 ) and employing the principles 
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of the invention. Rekeying during joins and leaves is identical to that of the 
embodiment for many-to-many communication. The receivers form n receivers 
subgroups 126; members of a receivers subgroup 126 share a common group key 
(Root Key/, 1 < / < n) among themselves and also employ the principles of the 
5 invention. Using the corresponding root key each subgroup member 22 can 
communicate with other members of the same subgroup. 

Each subgroup of receivers has at least one sender as a member 22b as shown 
in Figure 9. In other words some senders belong to two subgroups, the group of the 
senders and one of the groups of the receivers. The sender 22b that is part of a 
10 receivers 5 subgroup is responsible for group control of that subgroup. Note that group 
management overhead however is distributed among all the members of the receivers' 
subgroup, following the principles of the invention. 

Few-to-many group formation 

A few-to-many group may form in a number of different ways. For example, 
the senders first form the senders subgroup 124. Some of the senders may then begin 
to accept requests for membership from the receivers and form receivers 1 subgroups 
126. Our protocol also allows for limited data transmission by some of the receivers. 
When a receiver wants to send data, it contacts the sender that controls the subgroup it 
belongs to. If the sender approves the data transmission by the receiver, it forwards it 
to all the members of the few-to-many group 122. 

Alternatively, receivers subgroups 126 may be formed first and then leaders 
from the subgroups form the senders' subgroup 124 to initiate few-to-many 
communication. Corporate meetings are examples of such few-to-many groups. For 
example if ABC corporation has several branches M, N, Z, each branch location 
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first forms the receivers subgroups 126. Managers (leaders) from each group then 
form the senders subgroup 124 and start few-to-many group communication. 

Secure communication 

Each sender generates a session key and sends data encrypted with it to the 
5 few-to-many group. It then forwards the session key encrypted with Root Key 0 to the 
senders' subgroup 124. Each sender 22b that is member of a receivers' subgroup 126 
decrypts the session key, encrypts it with the receivers' subgroup key and forwards it. 
In Figure 9, Si decrypts the session key using Root Key 0 and encrypts it using Root 
Keyi. The use of a randomly generated session key for data transmission ensures that 
10 the receivers cannot send data. 

Alternatively, it is possible to use the senders' subgroup key, Root Key 0 for 
data transmission. In that case, multicast routers need to filter any data sent by the 
receivers. 

While the invention has been described in its presently preferred embodiment, 
15 it will be understood that the invention is capable of modification or adaptation 
without departing from the spirit of the invention as set forth in the appended claims. 
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Claims : 

1. A distributed group key management system for providing secure 
communication between a plurality of members, comprising: 

a binary distribution tree for defining a communication structure 
including an internal node having a first branch and a second branch depending 
5 therefrom, said internal node having a blinded key and an unblinded key, each of said 
branches including a first member assigned to a corresponding leaf node, said first 
member being associated with a key association group comprised of at least one other 
member; 

said first member including; 
IQ a unique binary ID associated with the corresponding leaf node 

to which the first member is assigned; 

a first secret key for contributing to the generation of the 

internal node blinded key; and 

a blinded key derived from said first secret key for exchanging 
15 with a blinded key of the at least one other member; 

wherein said first member uses the blinded key of the at least one other 
member and the first member first secret key to calculate an unblinded key of the first 
internal node to be used for encrypting data that is communicated between members 
located on branches depending from the first internal node. 
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2. The distributed group key management system of Claim 1 wherein said 
first member further includes a secret key generator for generating said first member 
first secret key. 

3. The distributed group key management system of Claim 1 wherein said 
first member further includes a key association group module for determining the key 
association group associated with the first member. 

4. The distributed group key management system of Claim 1 wherein said 
first member further includes a blinded key module for generating the .first member 
blinded key from the first member first secret key. 

5. The distributed group key management system of Claim 4 wherein the 
blinded key module includes a one way function for generating the first member 
blinded key. 

6. The distributed group key management system of Claim 1 wherein the 
first internal node is a root node. 
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7. The distributed group key management system of Claim 1 wherein said first 
member further includes: 

a key association group module for determining the key association 
group associated with the first member; 
; a secret key generator for generating the first member first secret key; 

and 

a blinded key module for generating the first member blinded key from 
the first member first secret key. 

8. The distributed group key management system of Claim 1 wherein said 
second branch includes a first member that is a member of the key association group 
associated with the first branch first member; and 

the first member further includes an unblinded key module having a 
5 mixing function for determining the unblinded key of the first internal node from the 
blinded key of the first branch first member and the blinded key of the second branch 
first member that is a key association group member associated with the first branch 
first member. 
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9. The distributed group key management system of Claim 1 wherein said 
first member further includes; 

a key association group module for determining the key association 
group associated with the first member; 
5 a secret key generator for generating the first member first secret key; 

and 

a blinded key module having a one way function for generating the 
first member blinded key from the first member first secret key; and 

an unblinded key module having a mixing function for determining the 
1 0 unblinded key of the first internal node. 
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10. A method of providing secure communications between at least two 
present members, comprising the steps of: 

providing a binary tree having at least one internal node and at least 
two leaf nodes, one of said internal nodes being a root node, each of said internal 
5 nodes having two branches extending therefrom, a first branch ending at one of said 
leaf nodes and another branch ending at another of said leaf nodes, a root path 
extending from each of said leaf nodes to said root node; 

assigning each of said present members to said leaf nodes, whereby 
each of said present members has a root path extending from a leaf node to said root 
10 node; 

assigning a binary ID to said internal nodes and leaf nodes; 

associating a secret key and a blinded key with each of said leaf nodes, 
wherein the blinded key is derived from the secret key; 

determining a key association group that is associated with a present 
15 member for dividing key distribution tasks, the key association group including a 
group node corresponding to each internal node in the root path of the present 
member, each group node having an associated member, said present member being 
assigned to a leaf node in the first branch of said root path internal node, each 
associated member being assigned to a leaf node in the other branch of said root path 
20 internal node; 

the present member sending to the associated member of the key 
association group a blinded key associated with the group node in the first branch of 
the root path internal node; 

the key association group associated member sending to the first 
25 member a blinded key associated with the group node in the other branch of the root 
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path internal node; 

determining an unblinded key of the root path internal node from the 
blinded key associated with the other branch group node and the blinded key 
associated with the first branch group node; 
30 encrypting data with the root path internal node blinded key; and 

communicating the encrypted data between members located on 
branches depending from the root path internal node. 
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11. The method of Claim 10 wherein the step of associating a secret key 
further comprises generating the secret key. 

12. The method of Claim 10 wherein the step of associating a secret key 
further comprises generating the blinded key from the secret key using a one way 
function. 

13. The method of Claim 10 wherein the steps of sending further include 
using a secure channel. 

14. The method of Claim 13 wherein the step of using the secure channel 
further includes using a public key to encrypt the blinded key of the present member 
and the blinded keys of the associated members. 

15. The method of Claim 10 wherein the step of determining the root path 
internal node unblinded key further includes applying a mixing function to the blinded 
key associated with the second branch node and the blinded key associated with the 
first branch node. 

16. The method of Claim 10 further comprising the step of removing a 
leaving member from the binary tree. 
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17. The method of Claim 16 wherein the step of removing includes the 
steps of: 

updating the binary ID of the present members; 

generating a new secret key for a neighbor of the leaving member, 
5 wherein the neighbor is the present member located next to the leaving member, said 
neighbor having a root path and a key association group including at least one 
associated member, 

initiating a swap of blinded keys between the neighbor and the 
associated member of the key association group of the neighbor, wherein the neighbor 
0 initiates the key swap; and 

determining the unblinded keys of the internal nodes on the root path 
of the neighbor. 

18. The method of Claim 10 further comprising the step of joining a new 
member to the binary tree. 
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19. The method of Claim 18 wherein the step of joining further comprises: 
sending a request to join from the new member to a local member of 
said present members; 

granting the request to join; 
5 splitting the binary ID of the local member into a first ID and a second 

ID, wherein the first ID is assigned to the local member and the second ID is assigned 
to the new member; 

generating a new secret key for the local member; 
generating a first secret key for the new member; 
10 generating a blinded key of the local member from the new secret key; 

generating a blinded key of the new member from the first secret key; 
exchanging the blinded key of the new member with the blinded key of 

the local member; 

determining a key association group that is associated with the new 
15 member for dividing key distribution tasks, the new member key association group 
including a group node corresponding .to each internal node in the root path of the 
new member, said new member being assigned to a leaf node in the first branch of 
said root path internal node, said group node having an associated member, each 
associated member being assigned to a leaf node in the other branch of the root path 
20 internal node of the new member; 

the new member sending to the associated member of the new member 
key association group a blinded key associated with a first node in the first branch of 
the root path internal node; 

the new member key association group associated member sending to 
25 the new member a blinded key associated with the group node in the other branch of 
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the root path internal node; and 

determining an unblinded key of the new member root path internal 
node from the blinded key associated with the new member other branch group node 
and the blinded key associated with the new member first node. 
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20. A method of joining a new member to a distributed communications 
system for secure communications between a plurality of local members, comprising 
the steps of: 

providing a binary tree having at least one internal node and at least 
5 two leaf nodes, one of said internal nodes being a root node, each of said internal 
nodes having two branches extending therefrom, a first branch extending to at least 
one of said leaf nodes, and a second branch extending to at least another of said leaf 
nodes, a root path extending from each of said leaf nodes to said root node; each of 
said local members having a binary ID, and being assigned to a leaf node; 
10 sending a request to join from a' new member to one of said local 

members of the communications system; 

determining a key association group that is associated with the local 
member for dividing key distribution tasks, the local member key association group 
including a group node corresponding to each internal node in the root path of the 
15 local member, said local member being assigned to a leaf node in the first branch of 
said root path internal node, said group node having an associated member, each 
associated member being assigned to a leaf node in the other branch of the root path 
internal node of the local member; 

granting the request to join; 
20 splitting the binary ID of the local member into a first ID and a second 

ID, wherein the first ID is assigned to the local member and the second ID is assigned 
to the new member, 

generating a local member new secret key; 
generating a new member first secret key; 
25 generating a local member blinded key from the local member new 
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secret key; 

generating a new member blinded key from the new member first 

secret key; 

sending the new member blinded key to the local member, 
30 sending the local member blinded key to the new member; 

calculating the blinded key and the unblinded key of the local member 

root path internal node; 

sending the local member root path internal node blinded key to the 
local member key association group associated member corresponding to the group 
35 node corresponding to the local member root path internal node; 

sending a blinded key of the group node corresponding to the local 
member root path internal node to the local member; and 

forwarding the group node blinded key corresponding to the local 
member root path internal node to the new member. 
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21. The method of Claim 20 wherein the step of sending the new member 
blinded key further comprises unicasting the blinded key of the new member to the 
local member. 

22. The method of Claim 20 wherein the step of sending the group node 
blinded key further comprises unicasting the group node blinded key to the local 
member. 

23. The method of Claim 20 wherein said internal nodes further include a 
blinded key further comprising the steps of: 

maintaining a version associated with the blinded key of the internal 

node; 

5 receiving the blinded key of the internal node; 

determining whether more than one version of the internal node 
blinded key has been received; and 

using a mixing function to combine the versions of the internal node 

blinded key. 

24. The method of Claim 20 wherein each of said internal nodes further 
includes an old blinded key, further comprising the steps of: 

receiving a new blinded key corresponding to an internal node; and 
applying a mixing function to the old blinded key and the new blinded 

5 key. 
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25. The method of Claim 20 wherein the binary ID includes a length, 

further comprising the step of: 

determining the present member having the binary ID with the shortest 
length; wherein the binary ID of the present member with the shortest length binary 
5 ID is split into the first ID and the second ID. 

26. A method of merging a first secure communications system with a 
second secure communications system, each of said communications systems 
including a plurality of members having a binary ID, each of said communications 
systems having a binary tree structure with a root node, said root node having a 
5 blinded key, comprising the steps of: 

sending a request to merge the first communications system with the 

second communications system; 

granting the request to merge; 

using a mixing function to combine the blinded key of the first 
1 0 communications system root node with the blinded key of the second communications 

system root node; 

appending a 1 to the binary ID of said first communications system 

plurality of members; and 

appending a 0 to the binary ID of each member of the second 

15 communications system. 
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27. A distributed group key management system for providing secure 
communication between a plurality of members, comprising: 

at least one sender binary distribution tree for forming a senders group; 
said at least one sender binary distribution tree defining a 
5 communication structure having a sender internal node with a first branch and a 
second branch depending therefrom, each of said branches including a first member 
assigned to a corresponding leaf node, said first member being associated with a key 
association group including at least one other member; 

said senders group first member including: 
10 a unique binary ID associated with the corresponding leaf node 

to which the senders group first member is assigned; 

a first secret key; and 

a blinded key derived from said first secret key for exchanging 
with a blinded key of the other senders group member; 

15 wherein said senders group first member uses the blinded key 

of the at least one other senders group member and the first secret key to calculate an 
unblinded key of the sender internal node to be used for encrypting and decrypting 
sending group data that is communicated between sending group members located on 
branches depending from the sender internal node; and 

20 at least one receiver binary distribution tree for forming a 

receivers group, said receivers group including at least one sender for communicating 

with said senders group; 

said at least one receiver binary distribution tree defining a 
communication structure having a receiver internal node with a first branch and a 
25 second branch depending therefrom, each of said branches including a first member 
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assigned to a corresponding leaf node, said first member being associated with a key 
association group including at least one other member; 

said receivers group first member including; 

a unique binary ID associated with the corresponding 
30 leaf node to which the receivers group first member is assigned; 

a first secret key operable for encrypting data; and 
a blinded key derived from said first secret key for 
exchanging with a blinded key of the other receivers group member, 

wherein, each of said senders is one of said senders group first 
35 members and one of said receivers group first members, said sender uses the blinded 
key of the other receivers group member and the first secret key of the sender to 
calculate an unblinded key of the receiver internal node to be used for encrypting and 
decrypting receivers group data that is communicated between said receivers group 
members located on branches depending from the receiver internal node. 



BNSDOC1D: <WO 0103365A1 J_> 



37 



WO 01/03365 PCT/US00/18583 

28. The distributed group key management system of Claim 27 wherein 
the receivers group data and the senders group data is a session key for decrypting 
second data that is encrypted with the session key. 

29. The distributed group key management system of Claim 27 wherein 
the receivers group data and the senders group data is communications data for 
communicating between senders group members and receivers group members. 
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